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Abstract 


This document defines the expected behaviour of a client to various 
aspects of a Voice Profile for Internet Mail (VPIM) message or any 
voice and/or fax message. 
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1. Introduction 


As Internet messaging evolves into unified messaging, the term 
"e-mail" no longer refers to text-only messages. Today's "e-mail" 
are often multi-media. That is, they can have numerous non-text 
parts. These parts can be attachments or can contain voice and/or 
fax. 


Each of voice, fax, and text have their own distinct characteristics, 
which are intuitive to the user. For example, each of these message 
types require a different media viewer (text editor for text, audio 
player for voice, and image viewer for fax), and the dimensions of 
message size are also different for all three (kilobytes for text, 


seconds for voice, and pages for fax). As a result, a message that 
includes more than one of these in its parts is termed a mixed media 
message. 


How the messaging client responds to, and acts on these differences 
is termed "Client Behaviour". This is dependent on the concept of 
"Message-Context" [2] (previously called primary content), which 
defines whether the message is a voice mail, fax, or text message. 
The client can utilize this header to determine the appropriate 
client behaviour for a particular message. 


Traditionally, a messaging "client" referred to some sort of visual 
interface (or GUI - graphical user interface) that was presented on 
the users computer. However, as messaging evolves to unified 
communications the actual form of the messaging client is expected to 
change. Today's email can often be viewed on wireless devices with 
very limited screens or even "viewed" over a telephone (i.e., 
listening to email as you would listen to voice mail through a TUI - 
telset user interface). 


The intent of this document is to be general and refer to all types 
of messaging clients, as the user's expectation of behaviour based on 
the type of message is not expected to change. However, some of the 
following concepts may tend towards the more common GUI client. 


2. Conventions Used in This Document 


In examples, "C:" and "S:" indicate lines sent by the client and 
server respectively. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [4]. 


Parsons € Maruszak Informational [Page 2] 


RFC 4024 Voice Messaging Client Behaviour July 2005 


3. Message Icon 


The preferred method to distinguish between voice, fax, and text 
messages on a GUI client is with a visual cue, or icon. A similar 
voice prompt or "earcon" would be used for TUI clients. 


As it is possible for the message to contain more than one media 
type, the icon should describe the primary message content, as 
defined by the "Message-Context" header. Obvious choices for the 
icon/message pairs would be a telephone for a voice message, a fax 
machine for a fax message, and an envelope for a text mail message. 
Similarly obvious for the earcons would be short spoken prompts like 
"voice message". 


This could be taken a step further, and have the GUI icon change to 
indicate that the message has been read as is currently done in some 
email clients (others do not change the icon but merely bold the 
message in the message list to indicate it is unread). For example, 
a telephone with the receiver off-hook could indicate that the voice 
message has been played. A fax machine with paper at the bottom, as 
opposed to the top, would show that the fax had been viewed. 
Finally, an open envelope indicates that a text message has been 
read. 


3.1. Proposed Mechanism 


As the choice of icon is determined by the primary message type, the 
client should obtain this information from the "Message-Context " 
message header. This header is defined in [2]. 


4. Sender’s Number Column 


As is the case with most email GUI clients today, important message 
information is organized into columns when presented to the user ina 
the summary message list. TUIs often present even briefer summaries 
to the user at the beginning of the session. Typical columns in the 
GUI client include the message subject, and the date the message was 
received. 


Another important piece of information for the user is the origin of 
the message. For a voice or fax message, the origin is typically a 
telephone or fax machine respectively, each of which has an 
associated telephone number. This telephone number is critical to 
the user if they wish to return the call. This should be presented 
accurately to the user (without making it an email address). 
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4.1. Proposed Mechanism 


Instead of forcing the telephone number into an email address, a new 
Internet message header can be used to hold the originating telephone 
number [3]. If the message is indicated as being a voice or fax 
message per [2], the client should extract the number, and display it 
to the user in a separate column. As this header is defined to only 
hold the digits of the telephone number, it is left to the client to 
add any separating characters (e.g., "-"). 


5. Message Size 


In the cases of large attachments, small clients (e.g., PDA) and slow 
links (e.g., wireless) there is also a need for the client to see the 
length of the message in a suitable format before opening it. 


Currently, message size is normally given in kilobytes (kB). This 

is sufficient for plain text messages, but while it may give a hint 
as to how good the compression algorithm is, kB is not very useful in 
knowing the size of a voice and/or fax message. Instead, the size 
should give an indication of the length of the message, i.e., the 
duration (in seconds) of a voice message, and the number of pages of 
a fax. Again, the message may contain multiple types, so the size 
displayed should be that of the primary content type, per [2]. 


5.1. Proposed Mechanisms 


There are three suggested methods to relay this information, of them, 
the first method is favored: 


5.1.1. MIME Header Content-Duration as described in RFC 2424 [5] 


For voice messages, the Content-Duration field of the main audio/* 
body part (as indicated by content-disposition per [1]) should be 
displayed as the length of the message. If there are several audio 
parts, an implementation may display the message size as an aggregate 
of the length of each. 


For fax messages a new MIME Header, Content-Page-Length, could be 
defined, similar to Content-Duration with the exception that number 
of pages would be specified, rather than number of seconds. (e.g., 
Content-Page-Length:3). This would be created at origination. 
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5.1.2. Message length indicated as a parameter of an Existing 
RFC 2045 [7] Content-Type Header Field 


This would be created at the source. This proposed method would 
allow the message length to be passed to the client by default in 
IMAP. Again the client would have to choose between the main voice 
message length or an aggregate message length for display. 


Content-Type Header Field example: 


Content-Type=audio/*; length=50 
Content-Type=image/tiff; pages=3 


5.1.3. Message length indicated as part of an existing RFC 2822 [9] 
Header Field 


This field would be created at the source and may include message 
length information, but because it is part of the message headers, it 
could also be amended on reception (by a local process). This method 
would allow the message length to be passed to any client by default 
and not require any client modification. If used, this field would 
indicate the aggregate length of all attachments. 


The advantage of this mechanism is that no new headers are required 
and it works with existing clients. The downside is that it 
overloads the subject field. 


Subject Header Field example: 


Subject=Voice Message (0:04) 
Subject=Fax Message (3p) 
Subject=Voice Message (0:14) with Fax (1p) 


6. Media Viewer 


When a message is initially opened, the client should, by default, 
open the proper media viewer to display the primary message content. 
That is, an audio player for voice messages, an image viewer for fax, 
and a text editor for text messages. Note that on a TUI, the viewer 
would render the media to sound (which would have varying effect 
depending on the media and available process). 


Where there is more than one body part, obviously the appropriate 


viewer should be used depending on which body part the user has 
selected. 
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In the case where several viewers are available for a single media 
type, the user should be prompted to select the desired viewer on the 
first occasion that the message type is encountered. That viewer 
should then become the default viewer for that media type. The user 
should have the ability to change the default viewer for a media type 
at any time. 


Note that it is possible that the media viewer may not be part of the 
client or local to the host of the client. For example, a user could 
select to play a voice message from a GUI and the message is played 
over a telephone (perhaps because the user has no desktop speakers). 
Additionally, a user listening to a unified messaging inbox over a 
TUI could chose to print a particular message to a nearby fax 
machine. 


6.1. Proposed Mechanism 


As mentioned, the default viewer displayed to the user should be the 
appropriate one for the primary message type. The client is able to 
determine the primary message type from the "Message-Context" message 
header per [2]. 


7. Mark Message as Read 


Obviously, the user must be able to know which messages they have 
read, and which are unread. This feature would also control the 
message icon or earcon as mentioned in section 1. 


With the proliferation of voice and fax messages, clients should only 
indicate that these messages are read when the primary body part has 
been read. For example, a voice message should not be indicated as 
read until the audio part has been played. The default is currently 
to mark a message read, when the first body part (typically text) is 
viewed. 


7.1. Proposed Mechanism 
Implementation of this feature on most clients is a local issue. 


For example, in the case of IMAP4 [6], these clients should only set 
the \SEEN flag after the first attachment of the primary content type 
has been opened. That is, if the message context is voice message, 
the \SEEN flag would be set after the primary voice message 
(indicated by content-disposition [1] or content-criticality [8]) is 
opened. 
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8. Security Considerations 


The desirable client behaviours described here are intended to 
provide the user with a better client experience. However, 
supporting the proposed behaviours described in this document does 
not make a client immune from the risks of being a mail client. That 
is, the client is not responsible for the format of the message 
received, it only interprets. As a result, messages could be spoofed 
or masqueraded to look like a message they are not to elicit a 
desired client behaviour. This could be used to fool the end user, 
for example, into thinking a message was a voice message (because of 
the icon) when it was not. 
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